So I get the need here, and it makes sense.

However rather than add a very ad hoc auth_timeout, I think I'd prefer a way to do this in a more generic way, potentially using midlewares, so that similar use cases can also be handled.

potentially using midlewares,

I feel like if middlewares received the connection, it would allow to change the timeout for the duration of the prelude, and it would also allow to fix #261.

The problem is that passing a new parameter would break existing middewares :/ But maybe I should bite the bullet, and also pass a Hash as third argument so that it's easier to make it evolve in the future.

It should also be able to check the middleware signature when they are registered, which should allow to fail early and ask users to update the signature, we might even be able to so some shenanigans to make them work in a degraded way.

Actually, I'm an idiot, client is already available to middlewares.

Can you try something like:

module RedisAuthTimeoutMiddleware
  def call_pipelined(commands, _config)
    if commands.any? { |c| c.first == "AUTH" }
      read_timeout_was = client.read_timeout
      client.read_timeout = 1
      begin
        super
      ensure
        client.read_timeout = read_timeout_was
      end
    else
      super
    end
  end
end

From what I can tell, the connection prelude never goes through middlewares. It’s still run directly on the raw connection (lib/redis_client.rb comment “The connection prelude is deliberately not sent to Middlewares”). Because of that, there’s no hook today to raise the timeout only for the AUTH handshake.

I’d happily switch to a middleware-based solution once the prelude is exposed to them; until then the auth_timeout knob is the only way to scope the higher budget without relaxing the global read/write timeouts.

The problem is that passing a new parameter would break existing middewares :/ But maybe I should bite the bullet, and also pass a Hash as third argument so that it's easier to make it evolve in the future.

I handled that by adding the context hash but only passing it when a middleware’s method signature accepts a third argument. Existing two-arg middlewares still get exactly the same call, while new ones can opt into the extra context.

From what I can tell, the connection prelude never goes through middlewares.

It very much does:

That comment is outdated.

I believe my example middleware would work, but if you have evidence it doesn't, please show me and I'll try to make the necessary change for it to work.

Here's what worked! Thanks for the assist. I'll close this ticket:

module RedisAuthTimeoutMiddleware
  def call_pipelined(commands, config, &block)
    if commands.any? { |cmd| cmd&.first == "AUTH" || (cmd&.first == "HELLO" && cmd.include?("AUTH")) }
      Rails.logger.info("[RedisAuthTimeoutMiddleware] bumping read_timeout to 0.5 during AUTH prelude")
      old_timeout = client.read_timeout
      client.read_timeout = 0.5
      begin
        super
      ensure
        client.read_timeout = old_timeout
      end
    else
      super
    end
  end
end

RedisClient.register(RedisAuthTimeoutMiddleware)

require "benchmark"
require "redis_client"

url  = "..."
...

redis_config = RedisClient.config(
  url: url,
  username: opts[:username],
  password: opts[:password],
  ssl: true,
  read_timeout: 0.005,
  write_timeout: 0.005
)

connect_time = Benchmark.realtime do
  client = redis_config.new_client
  client.call("PING")
ensure
  client&.close
end

puts <<~MSG
  IAM token generation: #{(iam_time * 1000).round(2)} ms
  Redis connect + TLS + AUTH: #{(connect_time * 1000).round(2)} ms
MSG

{"time":"2025-11-21T20:43:54.586+00:00","pid":5866,"request_id":"process-0bfe453aac72e7de1f0b7178","message":"[RedisAuthTimeoutMiddleware] bumping read_timeout to 0.5 during AUTH prelude","user_id":"","log_level":"4","dd":{"trace_id":"0","span_id":"0"},"ddsource":["ruby"]}
IAM token generation: 0.45 ms
Redis connect + TLS + AUTH: 10.34 ms

Perfect!